Summary

• pass matrix.target into the Linux wheel maturin build step
• fix the i686 manylinux setup script to avoid calling sudo inside the container

Why we are doing this

We are investigating release failures during the PyPI publish step. A strong hypothesis is that the release job may be failing because it downloads all wheel artifacts into a single directory with merge-multiple: true, and the current Linux workflow can produce duplicate filenames with different contents.

Specifically, the release pipeline has been seeing PyPI reject a Linux wheel with a Trailing data ZIP error. One plausible explanation is that two different artifacts are writing different bytes to the same merged output filename before publish.

What was happening before

The Linux wheel matrix includes both:

• x86_64-unknown-linux-gnu
• i686-unknown-linux-gnu

But the Linux maturin-action step was not receiving target: ${{ matrix.target }}.

That meant the i686 job was not actually building i686 wheels. Instead, it built for the default host target on the runner, which is x86_64. As a result:

• the wheels-i686-unknown-linux-gnu artifact contained files named like ...x86_64.whl
• those filenames collided with the real x86_64 Linux wheels during later artifact merging
• the colliding files were not byte-identical
• this is a plausible cause of the release publish failure we are investigating

So even if this is not the only issue in the release pipeline, it is a real bug and an important thing to eliminate while debugging the PyPI failure.

Why this fix

This change makes the Linux job build the target it claims to build.

While testing that change, the i686 job started failing for a second reason: the before-script-linux path tried to run sudo inside the manylinux i686 container, but /usr/bin/sudo is not available there. Since the container is already running with sufficient privileges for that setup step, the symlink can be created directly.

So this PR does two things that belong together:

• fix the missing target wiring so the i686 lane stops producing x86_64-named wheels
• make the real i686 setup path work in the manylinux container

Validation

• inspected release artifacts from recent runs
• confirmed that wheels-i686-unknown-linux-gnu previously contained ...x86_64.whl files
• confirmed those files differed from the real x86_64 artifact files despite sharing the same names
• ran CI on this branch and confirmed that, after wiring the target correctly, the i686 lane began exercising the real i686 path and exposed the container sudo issue addressed here